Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nUnderstanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nUnderstanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nUnderstanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nUnderstanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nUnderstanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nUnderstanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nSimilar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n
Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nThis story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n
Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n
Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nMany years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n
This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n
Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n
Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n
To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\nPic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white. Pic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing \u201care we improving?\u201d Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white. Pic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing \u201care we improving?\u201d Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white. Pic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
In some time I had categorized the increasing velocity trend as a myth. I did check this out with fellow coaches and found the situation more or less the same. There were exceptions where this trend was visible. I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing \u201care we improving?\u201d Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white. Pic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
In some time I had categorized the increasing velocity trend as a myth. I did check this out with fellow coaches and found the situation more or less the same. There were exceptions where this trend was visible. I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing \u201care we improving?\u201d Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white. Pic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
First, the number of working days in the sprints would vary, there would be holidays and large organization events. Second, the available capacity of the team members would vary due to leave, being unwell, training etc. There would be changes in the team composition too though not frequent. In some time I had categorized the increasing velocity trend as a myth. I did check this out with fellow coaches and found the situation more or less the same. There were exceptions where this trend was visible. I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing \u201care we improving?\u201d Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white. Pic: Kelly - Photography (pexels.com)<\/a><\/small><\/p>\n","post_title":"Increasing trend in the team velocity - a myth?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"increasing-trend-in-the-team-velocity-a-myth","to_ping":"","pinged":"","post_modified":"2024-01-29 14:28:28","post_modified_gmt":"2024-01-29 14:28:28","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20349","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"},{"ID":20288,"post_author":"18","post_date":"2022-07-18 21:08:43","post_date_gmt":"2022-07-18 15:38:43","post_content":"\n Many years back, when I was in the second year of M. Tech (Computer Sc.) program, my hostel mates who took Fortran Programming course, used to consult me when they had any difficulties in programming. On one such occasion, one hostelmate came to me. His teacher had told him that the program that he had written was too big and that he should use subroutines to make it smaller. My friend took the advice but he could not make program smaller. Instead, he ended up adding a few more lines to the code. He came to me for help. I asked him to show me what he had done.\u00a0 He had 200 lines of code which he broke in 4 parts of 50 lines, \u00a0made each part a subroutine and was planning to call these subroutines in the sequence. Obviously, the code size did not reduce. I explained to him the concept of the subroutine which performs a defined function and can be called from other parts of the code. So, one does not have to write code for that function again and again. We reviewed the logic of his program, identified couple of subroutines that could be called from multiple places and the code size came down to 40% of the original code. The code was easy to read, understand and maintain. My friend was thrilled to learn this!<\/p>\n\n\n\n This story illustrates what\nhappens when people implement concepts that they have not understood correctly.\nI often see such examples in the space of Agile adoption. Recently I came\nacross a team that has adopted agile and were following scrum practices\nreligiously. When I attended their daily stand up, I saw the meeting being\ndriven by the manager who was focused on addressing the UAT issues that were preventing\nthe Go-Live. Each UAT issues was discussed, actions were agreed upon with\ntimeline and after that the meeting ended. I asked them if the team updated the\nboard in their agile planning and tracking tool before coming to the meeting\nand the answer was negative. As I probed deeper, I discovered that the way user\nstories were formed, individually each story did not deliver value. Multiple\nstories together only would deliver business value. In the end I discovered\nthat they had stuck to their traditional waterfall development process and had\nintroduced agile practices on top of them, as a result they were \u201cdoing agile\u201d\nbut in reality, were practicing waterfall with additional overheads of Agile\npractices. They were \u201cdoing Agile\u201d but were far from \u201cbeing Agile\u201d. <\/p>\n\n\n\n Similar to the organization in\nthe above example, many IT organizations are jumping on Agile bandwagon without\nfully understanding what it takes. Their desire to adopt Agile has business\nreasons. Businesses today, need to respond quickly to the constantly changing\nbusiness environment. These responses are mostly enabled by the IT and hence IT\norganizations need to be Agile and respond quickly to the demands of\nbusinesses. However, adopting Agile is not just adopting some agile practices\nlike delivering something in a short period of two to four weeks and having a daily\nmeeting. It is much more than that. To understand this better, let\u2019s look at some\nfundamental facts that create agile organizations.<\/p>\n\n\n\n Understanding these fundamentals\nof Agile and adopting the practices with full understanding of the philosophy\nbehind them will enable \u201cBeing Agile\u201d. \nThis may sound simple as it is easy to understand intellectually but its\nimplementation could throw up challenges where the team would need help from an\nexpert or a coach who has the expertise and experience needed to navigate\nthrough those challenges. <\/p>\n\n\n\n To conclude, just adopting Agile practices\nsuch as daily meeting, retrospectives, having a tool like Jira or Rally to\nsupport Agile etc. will not help the IT organization to be Agile. That may help,\n\u201dDoing Agile\u201d but it will not deliver the benefits of Agile. What is needed is\nthe full understanding of Agile values and principles, creation of rightly\noriented, right sized, cross functional teams that are fully empowered, understanding\nof iterative and incremental approaches, focus on delivery of value to the customer,\nhaving customer engaged in the development and continuous focus on improvement\nand learning! These are essential to develop the Agile mindset and culture. Of\ncourse, this is something that will need time and conscious effort under the\nguidance of an expert.<\/p>\n","post_title":"What does \"Being Agile\" mean?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"what-does-being-agile-mean","to_ping":"","pinged":"","post_modified":"2024-01-25 13:21:32","post_modified_gmt":"2024-01-25 13:21:32","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=20288","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"2","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
First, the number of working days in the sprints would vary, there would be holidays and large organization events. Second, the available capacity of the team members would vary due to leave, being unwell, training etc. There would be changes in the team composition too though not frequent. In some time I had categorized the increasing velocity trend as a myth. I did check this out with fellow coaches and found the situation more or less the same. There were exceptions where this trend was visible. I was transparent with the leaders and managers and shared what was happening on the ground. That led us to the next level on knowing \u201care we improving?\u201d Besides the above other factors that can be looked at are the quality of the product, customer escalations, work load on the team and stories that are complete. All will show a positive trend, but may not be in black and white.
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\n
A simple exercise helped here, in fact I started this with the Scrum Master\/team initially, to ascertain that they are doing the right things.
Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to \u2013 what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn\u2019t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.
Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.<\/p>\n\n\n\n
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\nHow shall we know if we are improving?<\/h4>\n\n\n\n
A simple exercise helped here, in fact I started this with the Scrum Master\/team initially, to ascertain that they are doing the right things.
Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to \u2013 what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn\u2019t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.
Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.<\/p>\n\n\n\n
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\n
I accepted this fact and moved on, but there was another aspect - leaders or managers of the team would occasionally ask this question to the coach. That was tricky. <\/p>\n\n\n\nHow shall we know if we are improving?<\/h4>\n\n\n\n
A simple exercise helped here, in fact I started this with the Scrum Master\/team initially, to ascertain that they are doing the right things.
Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to \u2013 what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn\u2019t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.
Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.<\/p>\n\n\n\n
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\n So what?<\/h4>\n\n\n\n
I accepted this fact and moved on, but there was another aspect - leaders or managers of the team would occasionally ask this question to the coach. That was tricky. <\/p>\n\n\n\nHow shall we know if we are improving?<\/h4>\n\n\n\n
A simple exercise helped here, in fact I started this with the Scrum Master\/team initially, to ascertain that they are doing the right things.
Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to \u2013 what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn\u2019t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.
Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.<\/p>\n\n\n\n
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\n
There would be changes in the nature of the work, like moving to REST API that would impact the capability and so on and so forth.
The team would be aware of the variation in the planned velocity during planning itself. They would look at the variation in their velocity in the retrospective against planned as well as the past velocity and figure out the reason for the variation - but there would be variations.
I thought maybe in the next project or team I would be able to able see this increasing trend, but that moment never materialized. <\/p>\n\n\n\n So what?<\/h4>\n\n\n\n
I accepted this fact and moved on, but there was another aspect - leaders or managers of the team would occasionally ask this question to the coach. That was tricky. <\/p>\n\n\n\nHow shall we know if we are improving?<\/h4>\n\n\n\n
A simple exercise helped here, in fact I started this with the Scrum Master\/team initially, to ascertain that they are doing the right things.
Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to \u2013 what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn\u2019t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.
Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.<\/p>\n\n\n\n
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\n Stable teams but unstable capacity and capability<\/h4>\n\n\n\n
There would be changes in the nature of the work, like moving to REST API that would impact the capability and so on and so forth.
The team would be aware of the variation in the planned velocity during planning itself. They would look at the variation in their velocity in the retrospective against planned as well as the past velocity and figure out the reason for the variation - but there would be variations.
I thought maybe in the next project or team I would be able to able see this increasing trend, but that moment never materialized. <\/p>\n\n\n\n So what?<\/h4>\n\n\n\n
I accepted this fact and moved on, but there was another aspect - leaders or managers of the team would occasionally ask this question to the coach. That was tricky. <\/p>\n\n\n\nHow shall we know if we are improving?<\/h4>\n\n\n\n
A simple exercise helped here, in fact I started this with the Scrum Master\/team initially, to ascertain that they are doing the right things.
Leader and the scrum master do a walk thru of the velocity chart. The velocity chart would have variations and the scrum master would explain the reason for that variation. If the reason for the variation was not the capacity, then it would lead to \u2013 what is being done to prevent it?
Invariably there would be action items from the retrospective to address that. At times the action items worked, at times it wouldn\u2019t work or would be partial. Sometimes the leader would be aware as his help would have been sought. The leader could step in to help if he thought it was required.
Given the short iterations or sprints and the review and retrospective that follows, the leaders felt comfortable about the teams being on the right track. Leaders could look at the trend of the velocity and talk with the Scrum Master to understand the reasons and actions and also step in if needed.<\/p>\n\n\n\n
What has been your experience? I am sharing my perspective and would like to hear your views. <\/p>\n\n\n\n