There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

• If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
  • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

    Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

    We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

    Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

    Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

    Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

    Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

    While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

     To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

    In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

    You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

    Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

    So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

    When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

    The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

    One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

    At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

    To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

    So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

    Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

    At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

    Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

    What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

    Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

    Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

    When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

    In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

    I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

    Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

    \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

    Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

    What would be your advice to Manish?<\/p>\n\n\n\n

    Suggested Solution<\/strong><\/p>\n\n\n\n

    For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

    Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

    Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

    <\/figure>\n\n\n\n

    Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

    Suggested Solution :<\/p>\n\n\n\n

    Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

    IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

    <\/figure>\n\n\n\n

    Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

    Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

    Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

    Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

    Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

    Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

    As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

    Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

    Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

    Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

    As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

    When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

    Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

    Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

    Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

    Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

    PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

    Suggested Solution:<\/strong> <\/p>\n\n\n\n

    Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

    I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

    In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

    When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

    In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

    I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

    In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

    Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

    Page 2 of 3 Previous 1 2 3 Next

    \n

    Suggested Solution<\/strong><\/p>\n\n\n\n

    There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

    • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
      • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

        Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

        We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

        Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

        Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

        Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

        Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

        While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

         To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

        In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

        You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

        Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

        So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

        When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

        The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

        One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

        At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

        To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

        So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

        Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

        At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

        Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

        What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

        Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

        Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

        When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

        In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

        I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

        Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

        \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

        Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

        What would be your advice to Manish?<\/p>\n\n\n\n

        Suggested Solution<\/strong><\/p>\n\n\n\n

        For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

        Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

        Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

        Suggested Solution :<\/p>\n\n\n\n

        Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

        IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

        Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

        Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

        Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

        Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

        Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

        As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

        Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

        Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

        Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

        As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

        When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

        Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

        Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

        Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

        Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

        PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

        Suggested Solution:<\/strong> <\/p>\n\n\n\n

        Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

        I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

        In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

        When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

        In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

        I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

        In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

        Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

        Page 2 of 3 Previous 1 2 3 Next

        \n

        Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

        Suggested Solution<\/strong><\/p>\n\n\n\n

        There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

        • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
          • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

            Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

            We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

            Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

            Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

            Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

            Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

            While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

             To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

            In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

            You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

            Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

            So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

            When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

            The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

            One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

            At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

            To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

            So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

            Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

            At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

            Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

            What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

            Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

            Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

            When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

            In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

            I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

            Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

            \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

            Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

            What would be your advice to Manish?<\/p>\n\n\n\n

            Suggested Solution<\/strong><\/p>\n\n\n\n

            For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

            Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

            Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

            <\/figure>\n\n\n\n

            Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

            Suggested Solution :<\/p>\n\n\n\n

            Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

            IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

            <\/figure>\n\n\n\n

            Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

            Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

            Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

            Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

            Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

            Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

            As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

            Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

            Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

            Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

            As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

            When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

            Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

            Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

            Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

            Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

            PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

            Suggested Solution:<\/strong> <\/p>\n\n\n\n

            Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

            I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

            In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

            When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

            In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

            I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

            In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

            Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

            Page 2 of 3 Previous 1 2 3 Next

            \n

            To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

            Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

            Suggested Solution<\/strong><\/p>\n\n\n\n

            There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

            • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
              • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                 To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                What would be your advice to Manish?<\/p>\n\n\n\n

                Suggested Solution<\/strong><\/p>\n\n\n\n

                For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                <\/figure>\n\n\n\n

                Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                Suggested Solution :<\/p>\n\n\n\n

                Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                <\/figure>\n\n\n\n

                Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                Suggested Solution:<\/strong> <\/p>\n\n\n\n

                Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                Page 2 of 3 Previous 1 2 3 Next

                \n

                The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                Suggested Solution<\/strong><\/p>\n\n\n\n

                There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                  • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                    Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                    We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                    Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                    Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                    Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                    Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                    While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                     To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                    In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                    You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                    Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                    So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                    When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                    The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                    One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                    At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                    To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                    So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                    Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                    At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                    Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                    What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                    Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                    Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                    When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                    In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                    I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                    Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                    \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                    Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                    What would be your advice to Manish?<\/p>\n\n\n\n

                    Suggested Solution<\/strong><\/p>\n\n\n\n

                    For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                    Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                    Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                    <\/figure>\n\n\n\n

                    Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                    Suggested Solution :<\/p>\n\n\n\n

                    Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                    IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                    <\/figure>\n\n\n\n

                    Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                    Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                    Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                    Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                    Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                    Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                    As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                    Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                    Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                    Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                    As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                    When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                    Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                    Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                    Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                    Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                    PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                    Suggested Solution:<\/strong> <\/p>\n\n\n\n

                    Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                    I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                    In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                    When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                    In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                    I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                    In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                    Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                    Page 2 of 3 Previous 1 2 3 Next

                    \n

                    7. Culture of Continuous Improvement <\/p>\n\n\n\n

                    The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                    To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                    Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                    Suggested Solution<\/strong><\/p>\n\n\n\n

                    There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                    • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                      • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                        Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                        We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                        Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                        Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                        Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                        Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                        While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                         To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                        In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                        You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                        Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                        So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                        When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                        The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                        One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                        At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                        To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                        So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                        Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                        At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                        Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                        What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                        Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                        Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                        When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                        In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                        I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                        Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                        \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                        Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                        What would be your advice to Manish?<\/p>\n\n\n\n

                        Suggested Solution<\/strong><\/p>\n\n\n\n

                        For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                        Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                        Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                        <\/figure>\n\n\n\n

                        Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                        Suggested Solution :<\/p>\n\n\n\n

                        Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                        IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                        <\/figure>\n\n\n\n

                        Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                        Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                        Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                        Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                        Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                        Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                        As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                        Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                        Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                        Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                        As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                        When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                        Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                        Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                        Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                        Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                        PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                        Suggested Solution:<\/strong> <\/p>\n\n\n\n

                        Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                        I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                        In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                        When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                        In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                        I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                        In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                        Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                        Page 2 of 3 Previous 1 2 3 Next

                        \n

                        When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                        7. Culture of Continuous Improvement <\/p>\n\n\n\n

                        The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                        To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                        Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                        Suggested Solution<\/strong><\/p>\n\n\n\n

                        There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                        • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                          • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                            Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                            We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                            Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                            Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                            Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                            Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                            While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                             To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                            In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                            You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                            Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                            So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                            When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                            The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                            One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                            At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                            To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                            So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                            Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                            At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                            Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                            What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                            Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                            Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                            When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                            In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                            I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                            Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                            \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                            Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                            What would be your advice to Manish?<\/p>\n\n\n\n

                            Suggested Solution<\/strong><\/p>\n\n\n\n

                            For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                            Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                            Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                            <\/figure>\n\n\n\n

                            Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                            Suggested Solution :<\/p>\n\n\n\n

                            Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                            IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                            <\/figure>\n\n\n\n

                            Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                            Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                            Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                            Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                            Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                            Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                            As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                            Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                            Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                            Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                            As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                            When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                            Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                            Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                            Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                            Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                            PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                            Suggested Solution:<\/strong> <\/p>\n\n\n\n

                            Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                            I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                            In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                            When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                            In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                            I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                            In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                            Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                            Page 2 of 3 Previous 1 2 3 Next

                            \n

                            6. Be patient <\/p>\n\n\n\n

                            When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                            7. Culture of Continuous Improvement <\/p>\n\n\n\n

                            The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                            To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                            Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                            Suggested Solution<\/strong><\/p>\n\n\n\n

                            There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                            • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                              • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                 To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                What would be your advice to Manish?<\/p>\n\n\n\n

                                Suggested Solution<\/strong><\/p>\n\n\n\n

                                For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                <\/figure>\n\n\n\n

                                Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                Suggested Solution :<\/p>\n\n\n\n

                                Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                <\/figure>\n\n\n\n

                                Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                Page 2 of 3 Previous 1 2 3 Next

                                \n

                                Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                6. Be patient <\/p>\n\n\n\n

                                When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                Suggested Solution<\/strong><\/p>\n\n\n\n

                                There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                  • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                    Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                    We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                    Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                    Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                    Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                    Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                    While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                     To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                    In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                    You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                    Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                    So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                    When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                    The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                    One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                    At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                    To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                    So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                    Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                    At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                    Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                    What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                    Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                    Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                    When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                    In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                    I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                    Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                    \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                    Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                    What would be your advice to Manish?<\/p>\n\n\n\n

                                    Suggested Solution<\/strong><\/p>\n\n\n\n

                                    For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                    Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                    Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                    <\/figure>\n\n\n\n

                                    Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                    Suggested Solution :<\/p>\n\n\n\n

                                    Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                    IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                    <\/figure>\n\n\n\n

                                    Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                    Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                    Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                    Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                    Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                    Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                    As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                    Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                    Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                    Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                    As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                    When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                    Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                    Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                    Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                    Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                    PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                    Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                    Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                    I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                    In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                    When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                    In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                    I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                    In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                    Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                    Page 2 of 3 Previous 1 2 3 Next

                                    \n

                                    5. Ensure support from the organization<\/p>\n\n\n\n

                                    Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                    6. Be patient <\/p>\n\n\n\n

                                    When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                    7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                    The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                    To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                    Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                    Suggested Solution<\/strong><\/p>\n\n\n\n

                                    There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                    • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                      • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                        Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                        We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                        Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                        Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                        Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                        Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                        While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                         To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                        In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                        You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                        Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                        So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                        When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                        The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                        One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                        At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                        To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                        So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                        Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                        At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                        Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                        What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                        Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                        Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                        When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                        In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                        I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                        Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                        \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                        Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                        What would be your advice to Manish?<\/p>\n\n\n\n

                                        Suggested Solution<\/strong><\/p>\n\n\n\n

                                        For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                        Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                        Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                        <\/figure>\n\n\n\n

                                        Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                        Suggested Solution :<\/p>\n\n\n\n

                                        Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                        IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                        <\/figure>\n\n\n\n

                                        Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                        Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                        Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                        Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                        Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                        Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                        As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                        Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                        Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                        Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                        As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                        When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                        Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                        Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                        Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                        Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                        PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                        Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                        Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                        I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                        In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                        When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                        In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                        I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                        In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                        Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                        Page 2 of 3 Previous 1 2 3 Next

                                        \n

                                        When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                        5. Ensure support from the organization<\/p>\n\n\n\n

                                        Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                        6. Be patient <\/p>\n\n\n\n

                                        When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                        7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                        The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                        To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                        Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                        Suggested Solution<\/strong><\/p>\n\n\n\n

                                        There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                        • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                          • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                            Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                            We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                            Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                            Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                            Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                            Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                            While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                             To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                            In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                            You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                            Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                            So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                            When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                            The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                            One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                            At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                            To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                            So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                            Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                            At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                            Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                            What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                            Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                            Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                            When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                            In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                            I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                            Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                            \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                            Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                            What would be your advice to Manish?<\/p>\n\n\n\n

                                            Suggested Solution<\/strong><\/p>\n\n\n\n

                                            For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                            Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                            Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                            <\/figure>\n\n\n\n

                                            Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                            Suggested Solution :<\/p>\n\n\n\n

                                            Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                            IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                            <\/figure>\n\n\n\n

                                            Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                            Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                            Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                            Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                            Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                            Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                            As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                            Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                            Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                            Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                            As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                            When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                            Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                            Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                            Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                            Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                            PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                            Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                            Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                            I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                            In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                            When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                            In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                            I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                            In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                            Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                            Page 2 of 3 Previous 1 2 3 Next

                                            \n

                                            4. Lead by example <\/p>\n\n\n\n

                                            When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                            5. Ensure support from the organization<\/p>\n\n\n\n

                                            Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                            6. Be patient <\/p>\n\n\n\n

                                            When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                            7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                            The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                            To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                            Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                            Suggested Solution<\/strong><\/p>\n\n\n\n

                                            There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                            • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                              • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                 To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                What would be your advice to Manish?<\/p>\n\n\n\n

                                                Suggested Solution<\/strong><\/p>\n\n\n\n

                                                For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                <\/figure>\n\n\n\n

                                                Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                Suggested Solution :<\/p>\n\n\n\n

                                                Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                <\/figure>\n\n\n\n

                                                Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                Page 2 of 3 Previous 1 2 3 Next

                                                \n

                                                \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                4. Lead by example <\/p>\n\n\n\n

                                                When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                5. Ensure support from the organization<\/p>\n\n\n\n

                                                Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                6. Be patient <\/p>\n\n\n\n

                                                When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                Suggested Solution<\/strong><\/p>\n\n\n\n

                                                There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                  • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                    Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                    We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                    Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                    Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                    Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                    Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                    While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                     To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                    In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                    You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                    Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                    So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                    When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                    The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                    One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                    At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                    To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                    So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                    Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                    At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                    Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                    What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                    Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                    Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                    When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                    In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                    I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                    Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                    \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                    Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                    What would be your advice to Manish?<\/p>\n\n\n\n

                                                    Suggested Solution<\/strong><\/p>\n\n\n\n

                                                    For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                    Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                    Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                    <\/figure>\n\n\n\n

                                                    Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                    Suggested Solution :<\/p>\n\n\n\n

                                                    Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                    IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                    <\/figure>\n\n\n\n

                                                    Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                    Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                    Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                    Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                    Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                    Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                    As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                    Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                    Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                    Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                    As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                    When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                    Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                    Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                    Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                    Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                    PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                    Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                    Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                    I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                    In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                    When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                    In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                    I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                    In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                    Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                    Page 2 of 3 Previous 1 2 3 Next

                                                    \n

                                                    3. Maintaining optimal distance from the team<\/p>\n\n\n\n

                                                    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                    4. Lead by example <\/p>\n\n\n\n

                                                    When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                    5. Ensure support from the organization<\/p>\n\n\n\n

                                                    Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                    6. Be patient <\/p>\n\n\n\n

                                                    When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                    7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                    The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                    To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                    Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                    Suggested Solution<\/strong><\/p>\n\n\n\n

                                                    There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                    • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                      • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                        Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                        We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                        Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                        Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                        Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                        Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                        While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                         To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                        In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                        You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                        Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                        So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                        When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                        The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                        One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                        At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                        To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                        So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                        Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                        At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                        Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                        What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                        Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                        Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                        When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                        In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                        I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                        Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                        \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                        Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                        What would be your advice to Manish?<\/p>\n\n\n\n

                                                        Suggested Solution<\/strong><\/p>\n\n\n\n

                                                        For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                        Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                        Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                        <\/figure>\n\n\n\n

                                                        Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                        Suggested Solution :<\/p>\n\n\n\n

                                                        Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                        IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                        <\/figure>\n\n\n\n

                                                        Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                        Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                        Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                        Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                        Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                        Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                        As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                        Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                        Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                        Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                        As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                        When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                        Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                        Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                        Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                        Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                        PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                        Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                        Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                        I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                        In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                        When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                        In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                        I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                        In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                        Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                        Page 2 of 3 Previous 1 2 3 Next

                                                        \n

                                                        Having understood the purpose of the transformation, managers should be clear about the role they will play in the transformation and the way they need to change themselves for the success of the transformation. This step is critical and will influence the success of the transformation. In traditional management, managers are used to what we call as \u201cCommand and Control\u201d! They are the ones who make decisions and are responsible for the consequences of the decisions. Agile is a different paradigm. Managers need to lead and coach the teams into making decisions and make the team responsible for them. For an individual used to giving instructions this is not easy. When he\/she sees something not as per his\/her expectation, he\/she would tend to intervene and direct the team to change the course. The problem is further amplified by the fact that the team who has been used to taking instructions and executing them, will be quite eager to take instructions and move on. They are quite happy to say later, \u201cwe did as you told\u201d; effectively transferring the responsibility to the manager. Managers need to be aware of this trap and develop the skill to avoid it. When they see a problem, they should refrain from pointing it out directly and giving a solution. Instead, they should have a discussion with the team posing some probing questions which make the team discover the problem and they would propose the solutions too. Managers then should navigate the discussion to the best solution. It is quite possible that during the discussion the team may come up with a solution that is better than the solution, the manager had thought of. \u00a0This approach helps the growth of the team members and they start assuming responsibility for the team\u2019s deliveries. We can even say that developing agility means helping people grow and take responsibility. The manager\u2019s role here is, essentially, that of a catalyst. Typically, a catalyst does not participate in the process but facilitates it, accelerates it! <\/p>\n\n\n\n

                                                        3. Maintaining optimal distance from the team<\/p>\n\n\n\n

                                                        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                        4. Lead by example <\/p>\n\n\n\n

                                                        When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                        5. Ensure support from the organization<\/p>\n\n\n\n

                                                        Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                        6. Be patient <\/p>\n\n\n\n

                                                        When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                        7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                        The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                        To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                        Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                        Suggested Solution<\/strong><\/p>\n\n\n\n

                                                        There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                        • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                          • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                            Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                            We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                            Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                            Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                            Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                            Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                            While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                             To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                            In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                            You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                            Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                            So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                            When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                            The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                            One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                            At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                            To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                            So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                            Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                            At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                            Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                            What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                            Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                            Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                            When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                            In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                            I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                            Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                            \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                            Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                            What would be your advice to Manish?<\/p>\n\n\n\n

                                                            Suggested Solution<\/strong><\/p>\n\n\n\n

                                                            For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                            Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                            Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                            <\/figure>\n\n\n\n

                                                            Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                            Suggested Solution :<\/p>\n\n\n\n

                                                            Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                            IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                            <\/figure>\n\n\n\n

                                                            Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                            Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                            Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                            Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                            Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                            Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                            As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                            Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                            Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                            Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                            As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                            When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                            Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                            Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                            Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                            Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                            PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                            Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                            Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                            I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                            In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                            When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                            In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                            I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                            In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                            Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                            Page 2 of 3 Previous 1 2 3 Next

                                                            \n

                                                            2. Understand the new roles and the new leadership style <\/p>\n\n\n\n

                                                            Having understood the purpose of the transformation, managers should be clear about the role they will play in the transformation and the way they need to change themselves for the success of the transformation. This step is critical and will influence the success of the transformation. In traditional management, managers are used to what we call as \u201cCommand and Control\u201d! They are the ones who make decisions and are responsible for the consequences of the decisions. Agile is a different paradigm. Managers need to lead and coach the teams into making decisions and make the team responsible for them. For an individual used to giving instructions this is not easy. When he\/she sees something not as per his\/her expectation, he\/she would tend to intervene and direct the team to change the course. The problem is further amplified by the fact that the team who has been used to taking instructions and executing them, will be quite eager to take instructions and move on. They are quite happy to say later, \u201cwe did as you told\u201d; effectively transferring the responsibility to the manager. Managers need to be aware of this trap and develop the skill to avoid it. When they see a problem, they should refrain from pointing it out directly and giving a solution. Instead, they should have a discussion with the team posing some probing questions which make the team discover the problem and they would propose the solutions too. Managers then should navigate the discussion to the best solution. It is quite possible that during the discussion the team may come up with a solution that is better than the solution, the manager had thought of. \u00a0This approach helps the growth of the team members and they start assuming responsibility for the team\u2019s deliveries. We can even say that developing agility means helping people grow and take responsibility. The manager\u2019s role here is, essentially, that of a catalyst. Typically, a catalyst does not participate in the process but facilitates it, accelerates it! <\/p>\n\n\n\n

                                                            3. Maintaining optimal distance from the team<\/p>\n\n\n\n

                                                            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                            4. Lead by example <\/p>\n\n\n\n

                                                            When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                            5. Ensure support from the organization<\/p>\n\n\n\n

                                                            Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                            6. Be patient <\/p>\n\n\n\n

                                                            When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                            7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                            The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                            To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                            Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                            Suggested Solution<\/strong><\/p>\n\n\n\n

                                                            There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                            • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                              • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                                Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                                We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                                Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                                Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                                Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                                Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                                While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                                 To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                                In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                                You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                                Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                                So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                                When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                                The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                                One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                                At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                                To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                                So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                                Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                                At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                                Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                                What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                                Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                                Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                                When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                                In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                                I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                                Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                                \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                                Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                                What would be your advice to Manish?<\/p>\n\n\n\n

                                                                Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                                Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                                Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                                <\/figure>\n\n\n\n

                                                                Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                                \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                                Suggested Solution :<\/p>\n\n\n\n

                                                                Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                                IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                                <\/figure>\n\n\n\n

                                                                Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                                Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                                Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                                Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                                Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                                Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                                As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                                Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                                Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                                Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                                As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                                When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                                Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                                Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                                Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                                Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                                PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                                Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                                Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                                I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                                In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                                When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                                In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                                I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                                In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                                Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                Page 2 of 3 Previous 1 2 3 Next

                                                                \n

                                                                First and foremost, the managers have to have a strong buy-in into the Agile Transformation. Unless they have conviction in transformation, their support to it will be half-hearted and mechanical. Leadership needs to explain why Agile Transformation is needed and the difference it would make to the company. This explanation should be well assimilated by the managers. They should also undertake some self-study to understand the need for transformation and the roadmap for the same. <\/p>\n\n\n\n

                                                                2. Understand the new roles and the new leadership style <\/p>\n\n\n\n

                                                                Having understood the purpose of the transformation, managers should be clear about the role they will play in the transformation and the way they need to change themselves for the success of the transformation. This step is critical and will influence the success of the transformation. In traditional management, managers are used to what we call as \u201cCommand and Control\u201d! They are the ones who make decisions and are responsible for the consequences of the decisions. Agile is a different paradigm. Managers need to lead and coach the teams into making decisions and make the team responsible for them. For an individual used to giving instructions this is not easy. When he\/she sees something not as per his\/her expectation, he\/she would tend to intervene and direct the team to change the course. The problem is further amplified by the fact that the team who has been used to taking instructions and executing them, will be quite eager to take instructions and move on. They are quite happy to say later, \u201cwe did as you told\u201d; effectively transferring the responsibility to the manager. Managers need to be aware of this trap and develop the skill to avoid it. When they see a problem, they should refrain from pointing it out directly and giving a solution. Instead, they should have a discussion with the team posing some probing questions which make the team discover the problem and they would propose the solutions too. Managers then should navigate the discussion to the best solution. It is quite possible that during the discussion the team may come up with a solution that is better than the solution, the manager had thought of. \u00a0This approach helps the growth of the team members and they start assuming responsibility for the team\u2019s deliveries. We can even say that developing agility means helping people grow and take responsibility. The manager\u2019s role here is, essentially, that of a catalyst. Typically, a catalyst does not participate in the process but facilitates it, accelerates it! <\/p>\n\n\n\n

                                                                3. Maintaining optimal distance from the team<\/p>\n\n\n\n

                                                                \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                                4. Lead by example <\/p>\n\n\n\n

                                                                When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                                5. Ensure support from the organization<\/p>\n\n\n\n

                                                                Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                                6. Be patient <\/p>\n\n\n\n

                                                                When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                                7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                                The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                                To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                                Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                                Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                                • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                                  • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                                    Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                                    We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                                    Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                                    Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                                    Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                                    Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                                    While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                                     To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                                    In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                                    You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                                    Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                                    So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                                    When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                                    The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                                    One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                                    At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                                    To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                                    So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                                    Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                                    At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                                    Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                                    What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                                    Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                                    Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                                    When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                                    In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                                    I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                                    Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                                    \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                                    Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                                    What would be your advice to Manish?<\/p>\n\n\n\n

                                                                    Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                    For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                                    Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                                    Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                                    <\/figure>\n\n\n\n

                                                                    Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                                    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                                    Suggested Solution :<\/p>\n\n\n\n

                                                                    Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                                    IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                                    <\/figure>\n\n\n\n

                                                                    Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                                    Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                                    Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                                    Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                                    Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                                    Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                                    As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                                    Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                                    Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                                    Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                                    As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                                    When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                                    Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                                    Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                                    Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                                    Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                                    PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                                    Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                                    Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                                    I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                                    In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                                    When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                                    In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                                    I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                                    In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                                    Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                    Page 2 of 3 Previous 1 2 3 Next

                                                                    \n

                                                                    1.Align with the Purpose<\/p>\n\n\n\n

                                                                    First and foremost, the managers have to have a strong buy-in into the Agile Transformation. Unless they have conviction in transformation, their support to it will be half-hearted and mechanical. Leadership needs to explain why Agile Transformation is needed and the difference it would make to the company. This explanation should be well assimilated by the managers. They should also undertake some self-study to understand the need for transformation and the roadmap for the same. <\/p>\n\n\n\n

                                                                    2. Understand the new roles and the new leadership style <\/p>\n\n\n\n

                                                                    Having understood the purpose of the transformation, managers should be clear about the role they will play in the transformation and the way they need to change themselves for the success of the transformation. This step is critical and will influence the success of the transformation. In traditional management, managers are used to what we call as \u201cCommand and Control\u201d! They are the ones who make decisions and are responsible for the consequences of the decisions. Agile is a different paradigm. Managers need to lead and coach the teams into making decisions and make the team responsible for them. For an individual used to giving instructions this is not easy. When he\/she sees something not as per his\/her expectation, he\/she would tend to intervene and direct the team to change the course. The problem is further amplified by the fact that the team who has been used to taking instructions and executing them, will be quite eager to take instructions and move on. They are quite happy to say later, \u201cwe did as you told\u201d; effectively transferring the responsibility to the manager. Managers need to be aware of this trap and develop the skill to avoid it. When they see a problem, they should refrain from pointing it out directly and giving a solution. Instead, they should have a discussion with the team posing some probing questions which make the team discover the problem and they would propose the solutions too. Managers then should navigate the discussion to the best solution. It is quite possible that during the discussion the team may come up with a solution that is better than the solution, the manager had thought of. \u00a0This approach helps the growth of the team members and they start assuming responsibility for the team\u2019s deliveries. We can even say that developing agility means helping people grow and take responsibility. The manager\u2019s role here is, essentially, that of a catalyst. Typically, a catalyst does not participate in the process but facilitates it, accelerates it! <\/p>\n\n\n\n

                                                                    3. Maintaining optimal distance from the team<\/p>\n\n\n\n

                                                                    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                                    4. Lead by example <\/p>\n\n\n\n

                                                                    When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                                    5. Ensure support from the organization<\/p>\n\n\n\n

                                                                    Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                                    6. Be patient <\/p>\n\n\n\n

                                                                    When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                                    7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                                    The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                                    To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                                    Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                                    Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                    There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                                    • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                                      • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                                        Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                                        We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                                        Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                                        Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                                        Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                                        Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                                        While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                                         To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                                        In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                                        You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                                        Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                                        So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                                        When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                                        The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                                        One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                                        At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                                        To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                                        So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                                        Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                                        At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                                        Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                                        What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                                        Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                                        Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                                        When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                                        In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                                        I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                                        Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                                        \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                                        Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                                        What would be your advice to Manish?<\/p>\n\n\n\n

                                                                        Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                        For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                                        Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                                        Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                                        <\/figure>\n\n\n\n

                                                                        Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                                        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                                        Suggested Solution :<\/p>\n\n\n\n

                                                                        Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                                        IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                                        <\/figure>\n\n\n\n

                                                                        Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                                        Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                                        Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                                        Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                                        Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                                        Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                                        As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                                        Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                                        Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                                        Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                                        As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                                        When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                                        Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                                        Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                                        Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                                        Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                                        PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                                        Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                                        Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                                        I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                                        In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                                        When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                                        In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                                        I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                                        In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                                        Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                        Page 2 of 3 Previous 1 2 3 Next

                                                                        \n

                                                                        A critical aspect of Agile Transformation is that here we are not just adopting new practices or processes but we are approaching the software development in a totally new way which requires us to think and act differently. This change required in our behavior \u2013 the way we interact with each other, the things that we expect from others, the things that others expect from us, are all fundamentally different. Essentially, we are talking of transitioning to a new culture and hence we call this, a Transformation! For the success of such a transformation exercise, the role of management in the organization is very critical. In this blog, I have listed seven tips that will help managers change themselves to ensure the success of their organization\u2019s Agile Transformation. <\/p>\n\n\n\n

                                                                        1.Align with the Purpose<\/p>\n\n\n\n

                                                                        First and foremost, the managers have to have a strong buy-in into the Agile Transformation. Unless they have conviction in transformation, their support to it will be half-hearted and mechanical. Leadership needs to explain why Agile Transformation is needed and the difference it would make to the company. This explanation should be well assimilated by the managers. They should also undertake some self-study to understand the need for transformation and the roadmap for the same. <\/p>\n\n\n\n

                                                                        2. Understand the new roles and the new leadership style <\/p>\n\n\n\n

                                                                        Having understood the purpose of the transformation, managers should be clear about the role they will play in the transformation and the way they need to change themselves for the success of the transformation. This step is critical and will influence the success of the transformation. In traditional management, managers are used to what we call as \u201cCommand and Control\u201d! They are the ones who make decisions and are responsible for the consequences of the decisions. Agile is a different paradigm. Managers need to lead and coach the teams into making decisions and make the team responsible for them. For an individual used to giving instructions this is not easy. When he\/she sees something not as per his\/her expectation, he\/she would tend to intervene and direct the team to change the course. The problem is further amplified by the fact that the team who has been used to taking instructions and executing them, will be quite eager to take instructions and move on. They are quite happy to say later, \u201cwe did as you told\u201d; effectively transferring the responsibility to the manager. Managers need to be aware of this trap and develop the skill to avoid it. When they see a problem, they should refrain from pointing it out directly and giving a solution. Instead, they should have a discussion with the team posing some probing questions which make the team discover the problem and they would propose the solutions too. Managers then should navigate the discussion to the best solution. It is quite possible that during the discussion the team may come up with a solution that is better than the solution, the manager had thought of. \u00a0This approach helps the growth of the team members and they start assuming responsibility for the team\u2019s deliveries. We can even say that developing agility means helping people grow and take responsibility. The manager\u2019s role here is, essentially, that of a catalyst. Typically, a catalyst does not participate in the process but facilitates it, accelerates it! <\/p>\n\n\n\n

                                                                        3. Maintaining optimal distance from the team<\/p>\n\n\n\n

                                                                        \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nmanager has to strike a balance between being with the team and being away from\nthe team! While the manager needs to be with the team so that he\/she is aware\nof how team is doing, he\/she should be careful not to impact the team\u2019s ability\nto make decisions for themselves! The attention from the manager will also\ndepend on the stage of transformation that the team is in. In the early stages\nof transformation, team would need more facilitation and this need would\ndecrease as they get deeper in Agile thinking, behavior, practices and metrics!\nAs the team matures in agility, manager can afford to spend less time with\nthem.\n\n\n\n<\/p>\n\n\n\n

                                                                        4. Lead by example <\/p>\n\n\n\n

                                                                        When it comes to following the agile philosophy, the Manager has to lead by example. Small actions and gestures of the manager need to demonstrate the agile behavior that others will understand and follow. E.g. - a simple gesture like asking team members to take turns in conducting and leading meetings, gives a clear signal that they are the ones who decide how the team executes! \u00a0Normally, the manager should refrain from participation in the daily meeting. This will force the team to make decisions by themselves.\u00a0 However, as stated above, if the manager feels a need for intervention that should be done in a coaching manner, educating the team and letting them arrive at the right decisions. <\/p>\n\n\n\n

                                                                        5. Ensure support from the organization<\/p>\n\n\n\n

                                                                        Another aspect of manager\u2019s role is to help the team in issues that need resources from outside the team. Managers need to have good connections with their peers and seniors so that when needed, they can seek and get help from other parts of the organization.<\/p>\n\n\n\n

                                                                        6. Be patient <\/p>\n\n\n\n

                                                                        When a major change program requiring new learning and adopting new philosophy and practices is undertaken, there would be an impact on productivity in the initial days. Managers need to navigate patiently during these times. As agile practices are established there will be gain in productivity and eventually, the team will deliver at much higher productivity than before and will ensure continuous and faster delivery of value to the customers. While the impact on productivity needs to be absorbed, there should be no impact on the quality of deliveries to the customers. The team needs to be conveyed that they may deliver less for some time but there should be no compromise on quality. <\/p>\n\n\n\n

                                                                        7. Culture of Continuous Improvement <\/p>\n\n\n\n

                                                                        The last and very important responsibility of the manager, promoting Agile Transformation, is to set up the culture of continuous improvement. In the initial days of transformation, the manager may be required to help the team understand the purpose of the retrospectives, orienting them to attack a problem and not a person; helping them to open up and identify improvement actions. However, at least in the initial days of transformation, he may not physically attend the retrospectives as his presence may impact the team and they may not open up. \u00a0Once the practice of retrospectives is well-established, managers may attend them once in a while. \u00a0The manager should promote the practice of admitting mistakes and the manager should be no exception in this. If the manager makes a mistake, he\/she should admit it like others. This will promote openness in the team. Occasionally, the Manager should seek feedback from the team on himself\/herself and check if he\/she needs to change anything. This is best done in informal one on one sessions. The team members, while forthcoming with positive feedback; most of the times, will not be comfortable in giving negative feedback. So, the manager has to extract it skillfully reading between the lines, if required. Over time, as the team sees openness in the manager and their feedback being taken seriously and positively, they will open up and share their feedback more freely.<\/p>\n\n\n\n

                                                                        To conclude, managers are the pillars needed for the solid construction of Agile Transformation. They need to transform themselves first, to lead this change and lead it from the front! <\/p>\n","post_title":"Seven Tips for Managers in Agile Transformation","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"seven-tips-for-managers-in-agile-transformation","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:14","post_modified_gmt":"2024-01-25 13:24:14","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=18612","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17891,"post_author":"18","post_date":"2020-12-21 02:45:18","post_date_gmt":"2020-12-20 21:15:18","post_content":"\n

                                                                        Suresh, a scrum master, is preparing for the upcoming sprint planning session along with his product owner Ravi. One of their developers has suggested that the improvements to the search algorithm that she has identified, can be included in the next sprint and address the negative feedback received from the customer on search speed. However, if they include this work in the next sprint, they will have to deprioritize other work that could impact the delivery of the database changes promised to the reporting team and that could impact their delivery of new reports promised to the customer. While Ravi feels that performance improvements are more important, as they will make their customer happy, Suresh feels that database changes should not be delayed as he has committed their delivery to an external team. They are in a dilemma. Can you help them resolve this situation?<\/p>\n\n\n\n

                                                                        Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                        There are multiple options for Suresh and Ravi to consider: If they are able to give higher priority to database changes, there is no impact outside their team and they will go ahead with schedule already drawn. In this case, Ravi has to manage the customer\u2019s expectations on performance improvements and ensure that he sees value in other features being delivered and stays positive about the software and the team. <\/p>\n\n\n\n

                                                                        • If they chose to prioritize the performance improvements, then there is an impact on external dependency and in this case, they should not take the decision by themselves. They need to get the program management team involved and consider the impact of delay in meeting the dependency. That decision should be done only at the program level. <\/li><\/ul>\n\n\n\n
                                                                          • They may also consider the possibility of partially completing both the work items in the upcoming sprint. However, in this case, the work items need to be sliced vertically so that something of value is delivered at the end of the sprint. Further, there could be other constraints, such as resource constraints, that may have an influence on this path. <\/li><\/ul>\n\n\n\n

                                                                            Ravi and Suresh need to consider these options and make a practical decision that will keep their customer happy. Key point in the case of options (2) and (3), is to make this decision at the program level and not at the project level. The program management may consider taking help from the customer to ensure that customer is in sync with their thinking.<\/p>\n","post_title":"CHOW # 227 - Prioritizing Work Items","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-227-prioritizing-work-items","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:34","post_modified_gmt":"2024-01-25 13:24:34","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17891","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":17880,"post_author":"18","post_date":"2020-12-21 01:29:30","post_date_gmt":"2020-12-20 19:59:30","post_content":"\n

                                                                            We have been discussing factors that are critical to success in delivery. In my first blog in this series, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with a deadline in mind. The second blog, \u201cMaking Deadlines Effective<\/a>\u201d described how leaders need to navigate to ensure that deadlines are owned by the teams. While these are necessary at the project level, as we scale up to the program level, new complexities emerge which, if not managed correctly, can lead to failures. Let\u2019s take a look at them in this blog. We will first understand what a program is and then describe the factors to be paid attention to. This discussion would focus on the agile ways of program execution and where appropriate highlight how agile techniques are different, simpler, and promote agility. <\/p>\n\n\n\n

                                                                            Programs are essentially much bigger and complex undertakings that require multiple projects to be executed in a coordinated way. Usually, they have a bigger objective to achieve. \u201cLaunch of a new product\u201d, \u201cIncreasing market share of a product by certain percentage\u201d, \u201cCreation of a new capability\u201d, \u201cReducing unemployment rate\u201d, \u201cBuilding a new railway line\u201d etc. are some examples of programs. <\/p>\n\n\n\n

                                                                            Usually, programs have much longer timespans than the projects contained in them. Outputs of the component projects need to be integrated to achieve the program objectives.  Coordination of these projects is the key here. If any of the projects, does not meet its delivery objectives, it will have a cascading impact on dependent projects and that could multiply the impact on the objective of the program or may even cause the program failure. Therefore, it is critical that the execution of projects in a program is well-coordinated and the dependencies and risks across projects are managed carefully.<\/p>\n\n\n\n

                                                                            Now let us turn our attention to the practices that help when the program and its projects are executed in the agile way. In the agile world, emphasis is on reducing the dependencies. If the team can function independently and deliver by itself, that is ideal. However, when the dependencies cannot be avoided, techniques or practices that help to mitigate or manage the dependencies are needed. Agility requires the team to surface the difficulties early in execution. So, it is a good practice to identify the dependencies and risks across teams at the planning stage itself. Similar to sprint planning in agile projects, agile programs need to have a planning session for the incremental work to be done in a program. While the duration of project sprints could be in 2+ weeks with a preference for a shorter duration, program increments could have a duration of a few months, two or three months being quite common.   In this planning session, all the teams involved in the program come together and keeping in view the program objectives for the next increment, plan together who will deliver what, to whom and when, and make commitments to the program team. The output of the planning session could be visually summarized in a Program Board that depicts features or goals, their delivery dates and cross-team dependencies. Subsequently, during execution, these dependencies should be tracked in an ongoing manner throughout the execution of the program increment. For this purpose, Scrum of Scrums is a good mechanism, wherein one member of each scrum team participates in a meeting of all projects, to update other teams about the status of their work and how dependencies are handled.<\/p>\n\n\n\n

                                                                            Each dependency may be treated like a risk which the program management could formally record and act upon. There could be other risks as well. For the success of the program, all risks need to be addressed effectively. In traditional Program Management, project managers and program managers are tasked with the creation and maintenance of a risk tracker where, for each risk, its probability and impact in terms of cost are assessed and a risk score is attached. Further the project and program management have to ensure that risks are addressed effectively. In the Agile world, risk management is taken down to the entire team and the entire team would have a view of the visual presentation of the risks. This visual presentation is facilitated by the ROAM Board that provides a good picture. ROAM is an acronym for the statuses a risk may have. R stands for Resolved, O for Owned, A for Accepted and M for mitigated. When a team has thought through how the risk could be avoided or eliminated and has taken the necessary actions to ensure that risk does not materialize, the risk is said to be Resolved. When it is not clear as to how to resolve the risk, responsibility for the same is assigned to an individual who further works on resolving the risk either fully or partially. Such a person is said to be the owner of the risk and the risk is said to be Owned. When the team thinks that the probability of a risk is not high enough to invest time and money in addressing it and decides to accept the consequences of the risk, the risk is said to be Accepted. When the team has taken action to reduce the impact of the risk and has accepted the reduced impact, the risk is said to be Mitigated. Periodic review of the ROAM Board ensures that the project teams and the program team are in sync and the chances of successful execution of the program are enhanced. <\/p>\n\n\n\n

                                                                            While it is possible to have a Program Board and a ROAM\nBoard physically on the wall, it Is better to create them digitally using an\nagile tool. When the teams are distributed geographically, digital boards are a\nmust, to ensure that all the teams are looking at the same picture and transparency\nis maintained. <\/p>\n\n\n\n

                                                                             To summarize, risks\nand dependencies across projects of a program are threats to the programs. Surfacing\nthem early is required to create an ability to address them effectively. Surfacing\nand tracking them transparently, enhance the chances of success in a program. <\/p>\n","post_title":"Making Programs Successful","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-programs-successful","to_ping":"","pinged":"","post_modified":"2024-01-25 13:24:52","post_modified_gmt":"2024-01-25 13:24:52","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17880","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15484,"post_author":"18","post_date":"2020-08-09 21:42:48","post_date_gmt":"2020-08-09 16:12:48","post_content":"\n

                                                                            In my previous blog, \u201cProject without a Deadline does not complete<\/a>\u201d; we looked at the importance of starting a project with an end date in mind. In this blog, we are going to explore this subject of deadlines further and see how to make the deadlines effective. A deadline is a double-edged sword. It can motivate the teams and help them achieve a pinnacle of success or it can demotivate the teams and lead them to failure. Leaders need to navigate skillfully to ensure that deadlines cause a positive impact and lead to success. <\/p>\n\n\n\n

                                                                            You would remember that when the Government of India announced demonetization of Rs.500 and Rs.1000 banknotes in November 2016, banks had a tough time dealing with the situation that ensued. While at the front end, they were dealing with customers wanting to exchange old notes, at the back end, they also had to provide various new reports to the Government. Their IT systems did not have these reports before and they had to create these reports on the fly. Banks and their IT staff did a commendable job in creating these new reports at a short notice with stringent deadlines. They met this unprecedented challenge successfully. How did they manage it? What factors helped them to achieve this?<\/p>\n\n\n\n

                                                                            Firstly, the agile principle of business and IT people working together as one cohesive team was very well implemented. Business people were fully involved in software development, explained the requirements, tested the software, and ensured that correct reports were produced on time.  Secondly and more importantly, the agile principle of empowering the motivated team fully also was on display. An integrated team of business and IT people were fully focused on delivering what was asked for. When we have motivated teams, fully owning the outcome, success is the natural result. This aspect of team owning the outcome can work wonders and it is for leaders to promote that ownership. <\/p>\n\n\n\n

                                                                            So, the key differentiator in meeting the deadline is that the deadline has to be owned by the team. It may be proposed (not imposed) by the leader but it must be wholeheartedly accepted and owned by the team. If the team does not own the deadline, it will definitely lead to compromises. That leads us to seek an answer to the question \u2013 what makes the teams own the deadline?. <\/p>\n\n\n\n

                                                                            When a team perceives that the deadline is being imposed on them and it is unfair, they will not own it. There will be resistance. The team may work towards the deadline but the winning spirit that creates spectacular success and celebration will be missing. This will lead to compromised delivery or total failure. <\/p>\n\n\n\n

                                                                            The best way to set the deadline is to let the team set the deadline themselves. Leaders may explain various factors that impact the organization such as the need to be the first mover, the need to catch up with the competition which is racing ahead, the need to start the revenue generation, the need to urgently address a serious problem\/issue, the need to take advantage of an opportunity that is becoming available, the consequences of not meeting the regulatory requirements on time, etc. and let the team set the deadline. When the team understands why they are doing what they are doing and the importance of delivering it by a particular date, they will be truly committed to the deadline and the successful outcome. In this case, the deadline is not something imposed by the boss, but something that is driven and owned by the team. Drive to meet the deadline is internal and not external<\/p>\n\n\n\n

                                                                            One word of caution - deadlines must be realistic. We\ndefinitely do not advise the team to be burnt out chasing a deadline. In some instances,\nthere could be exceptions to this but it is advisable to let the teams run at a\npace that could be sustained in an ongoing manner. <\/p>\n\n\n\n

                                                                            At times, there could be a small gap between what needs to be achieved and what could be achieved in the given time by a particular team.  In such situations, leaders tend to apply pressure and force the team to plug the gap. This could be counterproductive, as the team may circumvent some process to meet the demand and natural consequence of this would be a fall in quality. Usually, it is better to let the team own the problem and devise some solution.  As general guidance, if anything is to be compromised let scope be compromised but not the quality. Leaders may step in to help with prioritization of the work items. <\/p>\n\n\n\n

                                                                            To summarize, for deadlines to be effective, they need to be owned by the teams, and rather than forcing the deadlines, leaders need to work with the teams to make them own the deadlines. <\/p>\n\n\n\n

                                                                            So far, our discussion has been around deadlines for projects. We will extend it to the program and portfolio levels in the next blog. <\/p>\n\n\n\n

                                                                            Milind Rumade<\/a><\/p>\n","post_title":"Making Deadlines Effective","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"making-deadlines-effective","to_ping":"","pinged":"\nhttps:\/\/pm-powerconsulting.com\/blog\/project-without-a-deadline-does-not-complete\/","post_modified":"2024-01-25 13:25:21","post_modified_gmt":"2024-01-25 13:25:21","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15484","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":15098,"post_author":"18","post_date":"2020-06-29 20:56:05","post_date_gmt":"2020-06-29 15:26:05","post_content":"\n

                                                                            At one stage of  my career, I was leading a CoE (Centre of Excellence) for Project Management. I was good at Project Management, I had used it for delivering my projects successfully and experienced its importance. Now I was entrusted with helping others acquire that knowledge and skill!  While teaching \u201cProject Management\u201d,  I discovered a fundamental law about projects which applies to all projects irrespective of their nature and size; irrespective of the way the they are  managed \u2013 Agile Project Management <\/a>or PMP Project Management!  And the law states \u2013 \u201cProject without a deadline does not complete\u201d. <\/p>\n\n\n\n

                                                                            Let me illustrate this with an example. In a fast growing startup company, engaged in the development of a software product, the product manager discovered a new feature that could add significant value to their product. He presented it to the CEO and the engineering manager. Engineering manager explained that he had other features in work and along with them engineering team was also busy in supporting customers with customer specific enhancements. So, the CEO and product manager agreed to assign lower priority to this new feature but emphasized that the new feature is very important. In his next review, CEO wanted to check the progress on the new feature and he discovered that it was not even touched by the engineering team. \u201cWe did not have time for it\u201d was the simple explanation. The company had limited resources and engineering manager could not think of taking up a lower priority development and in the process, the new feature that could deliver significant competitive advantage to the company was lying neglected. Around this time, they also learnt that a competitor was thinking on a similar feature. Now everybody felt the urgency to deliver the new feature and they set a target that first usable version of the new feature should be delivered in three months\u2019 time. The engineering team made the adjustments to their resource utilization and started working on it and managed to deliver the first version as required! <\/p>\n\n\n\n

                                                                            What made the difference? Simple act of setting a target date \u2013 the deadline! If that were not set, the company would have lost many more months and would have lost the early mover advantage! That is the difference a deadline can make! <\/p>\n\n\n\n

                                                                            Deadlines have psychological impact. They motivate the\nindividuals to act! Deadlines drive us to define scope, resources, time and\ncost required, based on which a plan can be prepared, tracked and delivered! <\/p>\n\n\n\n

                                                                            Goal setting is an important exercise in  an organization at all levels. HR demands that the Goals should be SMART (Specific, Measurable, Attainable, Realistic and Timebound)! Here it is well recognized that unless the goals are time-bound i.e. unless there is a deadline, the goal has no meaning! Without a date, it just becomes a wish or desire and not a goal! <\/p>\n\n\n\n

                                                                            When we accept a deadline, we make a commitment. That\ncommitment galvanizes us and imparts us the energy and enthusiasm, necessary\nfor achievement of the goal! There could be unexpected hurdles on the path but if\nwe are charged with the energy and enthusiasm, we will find the ways to overcome\nthem.  <\/p>\n\n\n\n

                                                                            In our life \u2013 professional as well as personal, there are some activities which are important and urgent which grab our attention and we have no option but to spend our time on them. However, in the process, at times, we neglect the activities that are important but not urgent. Training, acquiring new skills, spending time with the family,  meditation  are some examples of important but non urgent activities. It is very important to set a date and time for them, otherwise we would lose something significant in the long run. Their neglect could mean missing out on some high value life experiences. <\/p>\n\n\n\n

                                                                            I would like to narrate a personal experience to further emphasize this. As it happens with most people, some of my classmates decided to arrange a reunion of our schoolmates. They met a few times and discussed the topic. I was invited to take part in one such discussion. We revived good old memories of our school days and agreed that we must rediscover that friendship and bonding. We also realized that finding our schoolmates after 30 years of no contact will be a difficult task. But we decided to go about it anyway. Then I said, \u201cIf you are serious about it, let\u2019s set a date for this reunion and get started\u201d. My friends were unwilling to set a date as things looked very uncertain then. But I insisted on the date and we set a date that was six weeks later. We set a target to get at least 60% of the 130 batchmates to attend the reunion. A weekly review meeting also was fixed. When we met after a week, there was significant progress.  All of us had contacted 2-3 more classmates and got them invited to our review meeting. I and one more friend visited the school and got the addresses of our batchmates from the school register. We distributed the list among ourselves and decided to either visit those addresses or send letters there. As we could see the progress, we got better idea of how we could go about contacting people and arranging the reunion. We also realized that it would be better to budget more time. I agreed to postpone the date but insisted that the revised date be final and we must go all out to meet it. We revised our date to two weeks later. We even went ahead and booked the venue for that date. Now there was no looking back. We went all out in our efforts and as more people got contacted the initiative got further momentum and it all culminated in a memorable reunion with 92 (70.8%) of our schoolmates and 12 teachers attending the event! Looking back, I told my friends that this would not have happened if I had not insisted on the date in my first meeting with them! They had spent few months just discussing the idea but by setting the deadline, we could make the reunion happen in just two months!  <\/p>\n\n\n\n

                                                                            Dear readers, at this stage, I would like to ask you to look back at your life and list out the things that you wanted to do but have not done. Ask yourself a question, \u201cwhy did those things not happen?\u201d. You will realize the truth \u2013 Project without a deadline does not complete! <\/p>\n\n\n\n

                                                                            \nhttps:\/\/pm-powerconsulting.com\/experts\/milind-rumade\/\n<\/div><\/figure>\n","post_title":"Project without a deadline does not complete","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"project-without-a-deadline-does-not-complete","to_ping":"","pinged":"","post_modified":"2024-01-25 13:25:43","post_modified_gmt":"2024-01-25 13:25:43","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15098","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"14","filter":"raw"},{"ID":15083,"post_author":"18","post_date":"2020-06-21 19:14:30","post_date_gmt":"2020-06-21 13:44:30","post_content":"\n

                                                                            Manish has taken up the role of a Scrum Master in a new team\nwhich has recently adopted Agile. The team is responsible for support and\nmaintenance of a very important enterprise application and has adopted\niteration based delivery model. All the support and maintenance requests are\nraised through a ticketing tool and come to the team as tickets. They are\nrequired to deliver only high severity production defects  with quick turnaround; however, such defects\nare very rare. In fact, the team has not seen such a ticket in last few months.\nOther support and maintenance tickets are prioritized, higher priority ones\nwhich can be delivered in a two week period, are clubbed together and delivered\nat the end of a two week iteration. Tickets are treated as User Stories in the\nagile delivery management tool. Manish finds that most of the user Stories, require\nsome approvals before team could start working on them. Also, sometimes, team\nrequires some clarifications or data from the user and waits for them before\nstarting work on the ticket. These factors add to the overall turnaround time\nof the tickets and at times wastes time of the team members who wait for\napprovals or clarifications etc. Sometimes this leads to User Stories not getting\ndelivered in the iteration.   Manish wants to avoid this waste, improve the\ncycle time of user stories and overall productivity. <\/p>\n\n\n\n

                                                                            What would be your advice to Manish?<\/p>\n\n\n\n

                                                                            Suggested Solution<\/strong><\/p>\n\n\n\n

                                                                            For support and maintenance teams, Kanban model is better\nsuited as it helps in managing continuous flow of work. Manish could explore\nthat option and consider use of Kanban Board to have a good view of tickets in\nvarious states and Work in Progress.  However,\nlet\u2019s first examine what he could do in the current iteration based delivery\nmodel. <\/p>\n\n\n\n

                                                                            Each iteration is preceded by a Backlog Grooming session where\nUser Stories for upcoming iterations are examined, clarified and fully\nunderstood by the developers, making them ready for action by the developers. Manish\nand team could use the Backlog Grooming session to identify the prerequisites\n(approvals, clarifications etc.) required by User Stories and initiate actions for\nthose to be addressed. This way, by the time iteration starts, prerequisites\nwill get addressed and developers can then execute their actions without any\nwait.  This will help reduce the cycle\ntime and improve the productivity. <\/p>\n\n\n\n

                                                                            Now let\u2019s examine how Kanban helps in this situation. Refer to the figure below. Tickets logged by the Users arrive as user Stories in Arrival State. From Arrival state they move to Prerequisites state where their prerequisites are identified and actions for addressing prerequisites are initiated. User Stories for which prerequisites have been addressed are marked as \u201cReady \u201c.  User stories on which development is happening are in \u201cDevelopment\u201d State.  As soon as development is completed on a user Story it moves to next state \u2013 \u201cUser Confirmation\u201d. The developer who is free now, can pull a \u201cReady\u201d User story from \u201cPrerequisites\u201d State into \u201cDevelopment\u201d state and start working on it. User stories that are confirmed by users move to delivered state from where they can be moved to production. <\/p>\n\n\n\n

                                                                            <\/figure>\n\n\n\n

                                                                            Looking at the Kanban Board, team can get a good idea of how\nmany stories are in arrival queue, How many are waiting for prerequisites to be\naddressed, how many are ready to move to development, how many are in\ndevelopment, how many are waiting for user confirmation and how many are ready\nto move to production. Developer do not have to wait anywhere, cycle time is\nkept low and productivity high. <\/p>\n","post_title":"CHOW #196 - Improving Productivity of the support and maintenance teams","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"challenge-of-the-week-chow-196-improving-productivity-of-the-support-and-maintenance-teams","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:09","post_modified_gmt":"2024-01-25 13:26:09","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15083","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13690,"post_author":"18","post_date":"2020-01-07 02:31:55","post_date_gmt":"2020-01-06 21:01:55","post_content":"\n

                                                                            \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMahesh\nis a new scrum master who has recently joined a scrum team. Team has\nexperienced team members who have delivered software successfully in the past. They\nare quite confident in the technology being used in the project. They follow\nscrum practices mechanically. Mahesh is trying to change this. However, many times\nteam members do not listen to what Mahesh says and ignore him. Sometimes, they\ncarry out Mahesh\u2019s suggestions reluctantly. Mahesh is finding it difficult to\nlead this team and feels that he is not able to influence them. How do you\nthink Mahesh could navigate this situation and succeed ?\n\n\n\n<\/p>\n\n\n\n

                                                                            Suggested Solution :<\/p>\n\n\n\n

                                                                            Mahesh, is a new person in the team that is already formed and has established some ways of working that have been used before and deliveries have happened. Irrespective of whether these ways are good or not, \u00a0whether they deliver good quality and customer satisfaction or not, whether they can be improved or not; team believes that they have a working model and they want to stick to it. They \u00a0resist the change. This is a classic case of change being pushed from outside. Obviously, the first thing that Mahesh has to do is to establish the need for change. He has to identify some issues that team has faced, what caused those issues and how those issues could be handled better by the changes that he proposes. He has to explain and make the team understand why certain paradigms that they are working with do not work and the need for adoption of new paradigms. Once this is achieved, team will accept his leadership and will follow him. Mahesh has to keep in\u00a0 mind that knowledge workers do not respect positions. They respect knowledge and value addition. For acceptance by the team, Mahesh has to come across as a person who adds value. This alone will help him create his place in the team. He should consciously avoid getting into command and control mode or escalation to management, which he could be tempted to, out of frustration. That would lead to his failure as scrum master. Rather, he should stick to fundamentals of change management and go about it systematically. He should keep the management informed of the problem and his approach to resolve it. But he has to deal with the problem himself and not seek their direct intervention.<\/p>\n","post_title":"CHOW 178 \u2013 Scrum Master Acceptance","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-178-scrum-master-acceptance","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:28","post_modified_gmt":"2024-01-25 13:26:28","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13690","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13684,"post_author":"18","post_date":"2020-01-07 02:09:37","post_date_gmt":"2020-01-06 20:39:37","post_content":"\n

                                                                            IT industry in India is a young industry. Percentage of younger people employed in this industry, is\u00a0 much higher compared to other industries. Average age of an IT project team is around 25 years. To keep the costs down this industry recruits fresh graduates, enables them through some training and uses them in project deliveries. However, this has inherent risks which if not managed well, will cause project failures; whereas, if managed well, they can take the projects to glorious heights. Fresh graduates come with high energy, strong desire to learn, lot of enthusiasm and willingness to work hard. However, they lack proficiency in the tasks to be executed. So, most organizations arrange a fresh graduates training program and expect them to start delivering after the training. However, it is necessary to recognize that depending on their background, knowledge and skills, different individuals need different treatments for their evolution. This fact is overlooked and as a result, organizations achieve suboptimal results. It also causes stress to trainee individuals, impacting them negatively. Here, we present an approach that can avoid these unpleasant consequences and help inexperienced individuals evolve naturally and be effective, in course of time. This approach is based on the model shown in Figure 1 \u2013 \u201cAptitude Experience Model\u201d.<\/p>\n\n\n\n

                                                                            <\/figure>\n\n\n\n

                                                                            Figure 1 : Aptitude \u2013 Experience Model<\/strong><\/p>\n\n\n\n

                                                                            Using this model team members could be placed in one of the four quadrants depending on their Aptitude (x-axis) and Experience (y-axis).  Aptitude is the capability to perform certain tasks. This aptitude would be rated as high when the individuals have gone through some good training, have performed these tasks on trial assignments, have familiarity with pitfalls in the execution and can perform the tasks with relative ease. It would be rated as low when individuals have not gone through sufficient training and do not have good hands-on experience with the tasks to be executed. <\/p>\n\n\n\n

                                                                            Sometimes people get into tasks which they do not know about and have lot to learn before they perform that task. Fresh graduates with degree in core engineering (electrical, mechanical etc.), getting into an IT company to become software engineers fall in this category. Although they may have good academic background and may be very talented, they score low on Aptitude Axis as they have to learn a lot, to perform as software engineers. <\/p>\n\n\n\n

                                                                            Some people study software development as part of their academic curriculum, are familiar with sound software engineering practices, have gained good experience through delivery of useful software and enter IT industry with good abilities as programmers. These people score high on Aptitude Axis. However, to ensure right placement, we recommend use of an aptitude test.<\/p>\n\n\n\n

                                                                            Experience Axis refers to the useful experience of an individual in performing the desired tasks. Here, what matters is whether the individual has gained desirable experience that makes him productive. We recommend use of a suitable test for objective rating of individual's Experience.  <\/p>\n\n\n\n

                                                                            Quadrant\n1 is low Aptitude, low experience quadrant.  Here team members need to undertake significant\nlearning effort to be productive. They need to be guided and usually have to\nwork hard to deliver acceptable performance. They can be expected to make\nmistakes and hence their work needs to be reviewed carefully. Team lead should\nexpect lower productivity from the members in this quadrant. He should assign\nmentors who can spend more time with these team members and they need to be actively\nhelped and guided. Good guidance and training act as motivators to the team\nmembers in Quadrant 1. <\/p>\n\n\n\n

                                                                            As\nmembers in quadrant 1 gain experience, their mistakes will decrease, quality of\ntheir work will increase and need to monitor them will go down. At this stage, they\nwill begin the transition to Quadrant 2. <\/p>\n\n\n\n

                                                                            Quadrant\n2 is low aptitude, high experience quadrant. In this quadrant, productivity of\nthe members is at acceptable level. They can be given more responsibility and\neventually be assigned to higher roles. <\/p>\n\n\n\n

                                                                            Quadrant 3 is high Aptitude, low experience quadrant. Team members in this quadrant have requisite background and some useful experience. These individuals are fast learners. They not only learn fast but also start delivering faster, making fewer mistakes. Their productivity could be at acceptable level and their mentors need to be intelligent people who could understand and address their intellectual needs. Team members in this quadrant usually get frustrated when they are made to undergo the training that is meant for Quadrant 1 team members as they they already know those things. For them such a training is waste of time. <\/p>\n\n\n\n

                                                                            Fresh graduates start either in quadrant 1 or in quadrant 3. There is no possibility of transition between these two quadrants. <\/p>\n\n\n\n

                                                                            As the members in quadrant 3  gain experience, their knowledge and productivity increases and they transition to quadrant 4. For a team leader, members of quadrant 4 are most desirable. They are the best, a team can get. They deliver high quality and grow fast. They are reliable, deliver with higher productivity and can contribute to creativity and innovativeness. They contribute handsomely to making the team, self organized. <\/p>\n\n\n\n

                                                                            When\nmembers in Quadrant 2 work closely with members of  quadrant 4, their thinking and way of working\nalso evolves and they transition to quadrant 4 in course of time.<\/p>\n\n\n\n

                                                                            Organization\nshould make a conscious effort to retain the quadrant 4 team members. In the absence\nof such efforts, they  may just leave,\ntaking away their expertise and experience. Therefore, they need to be given\nproper roles and responsibilities, they should be intellectually challenged and\navenues for faster growth should be made available to them. Their contributions\nshould be recognized and they should be rewarded well.<\/p>\n\n\n\n

                                                                            Conclusion -  Team leaders need to understand which quadrant their team members belong to and provide appropriate inputs and mentoring to chart out their path to Quadrant 4. Building a capable team needs time and patience and specific actions customized for an individual. In short, the team leader needs to adopt the role of a coach; understand where his team members stand and actively help them to evolve. If team leader does not have the necessary skill, time and experience for this important task, they should take help of a professional coach.<\/p>\n\n\n\n

                                                                            Milind Rumade <\/p>\n","post_title":"Fresh Graduates to Professionals","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"fresh-graduates-to-professionals","to_ping":"","pinged":"","post_modified":"2024-01-25 13:26:56","post_modified_gmt":"2024-01-25 13:26:56","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13684","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13171,"post_author":"18","post_date":"2019-07-22 22:57:06","post_date_gmt":"2019-07-22 17:27:06","post_content":"\n

                                                                            Ajit is a scrum master with some experience in leading an agile team. He has been assigned to a new team and he finds the team in the middle of their first sprint planning meeting. The product owner (PO) is relatively new to his role and has gone through the required training. He has prepared the backlog and prioritized it.<\/p>\n\n\n\n

                                                                            PO briefs the team that goal of the sprint would be to deliver a key feature that customers are waiting for. Team reviews the user stories for this feature, does the estimation and concludes that all of them cannot be completed in one sprint and some of them will need to be deferred to the next sprint. The PO is willing to push all the stories not related to the desired feature to the next sprint but insists that all the stories for that feature be completed in current sprint. He says that it is necessary to deliver this feature right in this sprint as competition has already introduced it in their products and unless we deliver this feature quickly, we might lose some customers and business. Ajit tries to convince the PO that team will deliver higher priority User Stories in the current sprint and remaining stories will be delivered in the next sprint. However, PO still urges the team to find out the way to deliver all the user stories of the desired feature. He is of the opinion that if required, team should work extra hours and on holidays to achieve this goal. How do you think Ajit should handle this situation?<\/p>\n\n\n\n

                                                                            Suggested Solution:<\/strong> <\/p>\n\n\n\n

                                                                            Agility means adapting quickly to the changes in the environment. So, agile teams are expected to deliver faster. However, very often, we come across situations where we have a big list of things that need to be delivered and of course, we may not be able to deliver everything that has been asked, in a short time. In a situation like this, agile advises that we prioritize and things that have higher priority be delivered first. We should use Pareto Principle here and find the 20% of the functionality that deliver 80% of the benefits that user gets. Our PO needs to be skilled in use of Pareto principle and should be properly trained for the same.\u00a0 Also the team has to bear in mind that whatever they deliver has to be directly usable by the user. So, they can not compromise the quality of delivery. Usually, while attempting to deliver bigger scope than what they can reasonably manage, teams tend to compromise on testing and some other activities that ensure good quality. This defeats the purpose of the delivery and should be firmly avoided. There is no point in delivering something that the users are not able to use. So, the development team should have a realistic target agreed with the users and ensure its delivery with quality. Further, we should never plan for working extra hours and on holidays. Agile teams generate a good momentum and sustain that momentum in ongoing manner. Working additional hours and on weekends disrupt their momentum and prevents working at a constant pace. In the long run it demotivates the team and may even cause burn out of team members. Therefore, except for exceptional situation that calls for exceptional response, working outside normal working hours and normal working days is to be avoided by the agile team. Ajit has to communicate this effectively to the PO. I would advise him to do this in a personal, face to face meeting with PO and get him in sync with agile ways of execution. The PO has to understand that what he is asking for is neither good for the organization; nor good for the team. If required, Ajit may take help of his Agile Coach or Agile sponsor to influence the PO. <\/p>\n","post_title":"Chow #158 - Demand vs Capacity","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-158-demand-vs-capacity","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:35","post_modified_gmt":"2024-01-25 13:28:35","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13171","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"},{"ID":13168,"post_author":"18","post_date":"2019-07-22 22:42:04","post_date_gmt":"2019-07-22 17:12:04","post_content":"\n

                                                                            I did B.E. in Electrical engineering from VJTI, Mumbai\nUniversity. As electrical engineers we studied electrical motors, generators,\ntransformers, electrical power generation and distribution etc, etc. . .  However, I did not like any of the electrical\nengineering subjects. I liked to study electronics. When I got introduced to\nDigital electronics and computers, I loved them.  Computers fascinated me \u00ad\u00ad\u00adand my heart\nlonged to study computers in depth. <\/p>\n\n\n\n

                                                                            In the last year of engineerin\u00ad\u00adg, companies started\nvisiting our college for campus recruitment. All these companies offered a job\nin electrical engineering. I was not interested in those jobs and was thinking\non pursuing higher studies in computer science. However, there was uncertainty\nin getting admission to a course of my choice. So, I decided to secure a job as\nfallback option. I decided to apply for the jobs that were available. I had\ngood academic record. All the companies conducted written test first and based\non performance in written test, candidates were shortlisted for interviews. I did\nvery well in written tests and was always shortlisted for interview. However,\nafter interview I did not get selected. My friends with not so great academic\nperformance also got job offers but I didn\u2019t. Our training and placement\nofficer was particularly surprised at this and even conducted a personal\nsession for me on how to handle interviews. Even then, the same pattern of\ngetting rejected in interviews continued. Towards end of recruitment sessions,\none software company came to our college and I appeared for their selection\nprocess. As usual I did well in written test and got shortlisted for interview.\nI appeared for interview and this time I was the first one to be selected and I\ngot an offer that was 50% higher than average offer received by my classmates.\nMy classmates showered me with congratulations and I also felt proud.  Subsequently, I did not join this company\nalso as I got admission to M. Tech. (Computers Science) course in IIT Bombay\nand decided to pursue my interest and studies in computers. After completion of\nM. Tech. degree I was selected by TCS in the first interview that I faced and\nthereafter I have not failed in any interview. \n<\/p>\n\n\n\n

                                                                            When I looked back on these events, I wondered why despite\nexcellent academic record, excellent performance in written tests and correct\nanswers to technical questions in interviews, I always got rejected in\ninterviews by electrical companies. I could not figure it out but I think my\ndislike for electrical engineering job somehow surfaced in those interviews and\nreflected in my body language and that led to rejections.  These rejections impacted me as I had\nsincerely tried to get the job. I got frustrated and became angry with myself.\nFor the first time in my life, my confidence was shaken. However all of that\nvanished when I got an offer from the software company. In hindsight, I think these\nrejections were a blessing in disguise. They helped me understand my strengths\nand passions better and made me more determined to prove myself and eventually\nI succeeded. They taught me an important lesson \u2013 failures are possible in\nspite of careful preparation if your heart is not into that activity. Being\npassionate about the outcome is one of the key ingredients of success. So,\nfailures are not necessarily bad! They have their own place of importance in\nour lives. They may close one avenue for us but at the same time they open up\nnew options that lead us in directions not easily comprehended before. <\/p>\n\n\n\n

                                                                            In the present age, marked by Volatility, Uncertainty,\nComplexity and Ambiguity (VUCA) one may not be fully prepared to face the\nchallenges and chances of failure are high. Here, we advise agile approaches.\nGet started, try something. If it fails, fine! Learn from the failure and\ncorrect your course and march on towards success!<\/p>\n\n\n\n

                                                                            I have worked for a product company that was an ambitious\nstart up. Company had fast growth and frankly, we were a bit overwhelmed by the\nspeed of growth. However, we were determined to make the company successful and\ndo whatever it takes for it. One of our delivery managers, was given the\nresponsibility of making an important delivery to a strategically important\ncustomer. Looking at too many things on his plate, he committed a delivery date\nthat was 11 months away, little short of one year. He then got busy with his\nother deliveries. After about  8 months,\nsomeone remembered this customer and it was discovered that work on this\nimportant delivery had not started and it was just not possible to meet the\ndate promised to the customer. When this was discovered, there was panic in the\nair. This manager was a very competent technical person and was very honest,\nsincere and hardworking. He was well respected in the company. Obviously, he\nwas dismayed and considered himself personally responsible for getting the\ncompany into the problem. When CEO called him, he expected to be fired. He\nprepared a resignation letter, put that in the pocket and went for the meeting.\nIn the meeting, he took complete responsibility for what had happened. He\nexplained that while he was busy and could not have started this important\ndelivery as he did not have people to work on it, he should have highlighted\nthat in time and failure to do so has landed company in the difficulty. Given\nthat situation he felt that he does not deserve this responsible position and offered\nto quit. The CEO smiled and said, \u201cWe have already lost something here. If you\nquit, we would lose some important lessons that this situation has taught us. I\ndo not want to lose them. Get back to the drawing board. Let me know what could\nbe the earliest date for this delivery and what you need to make it happen.\nAlso propose some changes that we should implement to prevent recurrence of\nthis kind of situations. We have failed as a team here and we need to work as a\nteam to recover from it \u2013 all of us; me included!\u201d Everybody in the company was\nrelieved at this decision and we committed ourselves to recover from the\nsituation. That was a great lesson for all of us in dealing with a failure. <\/p>\n\n\n\n

                                                                            In the same product company, we had to deal with many new technologies. Technical team was empowered to make suggestions which they thought were useful for the product. Sometimes these experiments did not work and some precious effort and money was lost. However. the CEO never discouraged them. He used to say, \u201cIt is ok to fail when we are doing something first time. But we should learn from the failures and improve.\u201d This approach took the fear of failure away from the team. This assurance of safety, fostered creativity in the environment. It enhanced the feeling of trust in the team and made them more responsible in their behavior. To summarize, never be afraid of failures. Failures are not necessarily bad! Use them to discover new avenues, new opportunities that can use your inherent strengths and create new definition of success. When we experiment we do take risks and may face failures. However, learning from failures will help us succeed eventually. Always keep in mind that failures are integral part of success! <\/p>\n\n\n\n

                                                                            Milind<\/a><\/p>\n","post_title":"Dealing with failures","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"dealing-with-failures","to_ping":"","pinged":"","post_modified":"2024-01-25 13:28:57","post_modified_gmt":"2024-01-25 13:28:57","post_content_filtered":"","post_parent":0,"guid":"http:\/\/pm-powerconsulting.com\/?p=13168","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"0","filter":"raw"}],"next":false,"prev":true,"total_page":2},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};

                                                                            Page 2 of 3 Previous 1 2 3 Next

                                                                            Milind Rumade

                                                                            

                                                                            Agile

                                                                            Seven Tips for Managers in Agile Transformation

                                                                            by Milind Rumade

                                                                            April 25, 2021

                                                                            

                                                                            Chow

                                                                            CHOW # 227 – Prioritizing Work Items

                                                                            by Milind Rumade

                                                                            December 21, 2020

                                                                            

                                                                            Agile

                                                                            Making Programs Successful

                                                                            by Milind Rumade

                                                                            December 21, 2020

                                                                            

                                                                            Agile

                                                                            Making Deadlines Effective

                                                                            by Milind Rumade

                                                                            August 9, 2020

                                                                            

                                                                            Agile

                                                                            Project without a deadline does not complete

                                                                            by Milind Rumade

                                                                            June 29, 2020

                                                                            

                                                                            Chow

                                                                            CHOW #196 – Improving Productivity of the support and maintenance teams

                                                                            by Milind Rumade

                                                                            June 21, 2020

                                                                            

                                                                            Chow

                                                                            CHOW 178 – Scrum Master Acceptance

                                                                            by Milind Rumade

                                                                            January 7, 2020

                                                                            

                                                                            Leadership

                                                                            Fresh Graduates to Professionals

                                                                            by Milind Rumade

                                                                            January 7, 2020

                                                                            

                                                                            Chow

                                                                            Chow #158 – Demand vs Capacity

                                                                            by Milind Rumade

                                                                            July 22, 2019

                                                                            

                                                                            Leadership

                                                                            Dealing with failures

                                                                            by Milind Rumade

                                                                            July 22, 2019

                                                                            Page 2 of 3 Previous 1 2 3 Next

                                                                            

                                                                            PM Power Consulting helps organizations achieve agility in design and delivery of software and services.

                                                                            Our Offerings

                                                                            © 2025

                                                                            PM Power Consulting

                                                                            Linkedin Facebook Youtube

                                                                            Search for:Search Button