Chow
July 4, 2021
1 Comment
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
![\"\"](\"https:\/\/pm-powerconsulting.com\/wp-content\/uploads\/2020\/06\/Hydel.jpg\")
<\/figure><\/div>\n\n\n\nThe key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\nThe key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n
I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\nThe key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n
Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n
I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\nThe key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n
Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n
Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n
I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\nThe key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n
Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n
I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n
Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n
In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n
He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n
Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n
He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n
At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
\u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
The anti-patterns are not proprietary to Agile; in my view, we can see anti-patterns of \"Waterfall\" even today.\u00a0 <\/p>\n\n\n\n Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
To\nsummarize, Royce, clearly identifies the risk in sequential flow of work (what\nis now popularly referred to as \u201cWaterfall\u201d), introduces iteration with\nfeedback and further goes on to recommend operational deployment of the second\nversion.<\/p>\n\n\n\n The anti-patterns are not proprietary to Agile; in my view, we can see anti-patterns of \"Waterfall\" even today.\u00a0 <\/p>\n\n\n\n Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
He goes\non to say that, \u201cIt is simply the entire process done in miniature, to a time\nscale that is relatively small, with respect to the overall effort\u201d. This justifies its necessity when there are\nnew elements and unknown factors (similar to what in Agile many today call as\n\u201cSpike\u201d).<\/p>\n\n\n\n To\nsummarize, Royce, clearly identifies the risk in sequential flow of work (what\nis now popularly referred to as \u201cWaterfall\u201d), introduces iteration with\nfeedback and further goes on to recommend operational deployment of the second\nversion.<\/p>\n\n\n\n The anti-patterns are not proprietary to Agile; in my view, we can see anti-patterns of \"Waterfall\" even today.\u00a0 <\/p>\n\n\n\n Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
If the computer program in\nquestion is being developed for the first time, arrange matters so that the\nversion finally delivered to the customer for operational deployment is\nactually the second version insofar as critical design\/operations areas are\nconcerned.<\/em><\/p>\n\n\n\n He goes\non to say that, \u201cIt is simply the entire process done in miniature, to a time\nscale that is relatively small, with respect to the overall effort\u201d. This justifies its necessity when there are\nnew elements and unknown factors (similar to what in Agile many today call as\n\u201cSpike\u201d).<\/p>\n\n\n\n To\nsummarize, Royce, clearly identifies the risk in sequential flow of work (what\nis now popularly referred to as \u201cWaterfall\u201d), introduces iteration with\nfeedback and further goes on to recommend operational deployment of the second\nversion.<\/p>\n\n\n\n The anti-patterns are not proprietary to Agile; in my view, we can see anti-patterns of \"Waterfall\" even today.\u00a0 <\/p>\n\n\n\n Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Royce goes on to recommend, \u201cDo it Twice\u201d. To Quote:<\/p>\n\n\n\n If the computer program in\nquestion is being developed for the first time, arrange matters so that the\nversion finally delivered to the customer for operational deployment is\nactually the second version insofar as critical design\/operations areas are\nconcerned.<\/em><\/p>\n\n\n\n He goes\non to say that, \u201cIt is simply the entire process done in miniature, to a time\nscale that is relatively small, with respect to the overall effort\u201d. This justifies its necessity when there are\nnew elements and unknown factors (similar to what in Agile many today call as\n\u201cSpike\u201d).<\/p>\n\n\n\n To\nsummarize, Royce, clearly identifies the risk in sequential flow of work (what\nis now popularly referred to as \u201cWaterfall\u201d), introduces iteration with\nfeedback and further goes on to recommend operational deployment of the second\nversion.<\/p>\n\n\n\n The anti-patterns are not proprietary to Agile; in my view, we can see anti-patterns of \"Waterfall\" even today.\u00a0 <\/p>\n\n\n\n Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n \u201cBecause in Waterfall \u2026......<\/em>\"<\/p>\n\n\n\n Sairam<\/a><\/p>\n","post_title":"The Waterfall I enjoyed in my Agile Journey","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"the-waterfall-i-enjoyed-in-my-agile-journey","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:36","post_modified_gmt":"2024-01-25 13:55:36","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=17413","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"4","filter":"raw"},{"ID":15501,"post_author":"27","post_date":"2020-08-10 11:13:12","post_date_gmt":"2020-08-10 05:43:12","post_content":"\n The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.\u00a0 They could not meet their sprint goal.\u00a0 They repeatedly failed to create a product increment.\u00a0 This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.\u00a0 A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.\u00a0 The team said they are adhering to their \u2018Definition of Ready\u2019 (DoR) before picking up any backlog item.\u00a0 In spite of that, they could not come out of this vicious circle.\u00a0 Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.<\/p>\n\n\n\n Suggested Solution<\/strong><\/p>\n\n\n\n Definition of Ready (DoR) \u2013 is something that is \u2018custom created\u2019 by\nthose Scrum practitioners who are fond of naming the processes, roles and\nartefacts. There is nothing called\nDefinition of Ready (DoR) in Scrum, but only Definition of Done (DoD). There is a deep-rooted reason for this. To simply state, an empirical development having\na potential for requirement discovery, can never ascertain requirement\nreadiness. I observed that people have\ncoined DoR to have an equivalent to a signed-off requirement, or for something\nthat implies a well-defined requirement or a specification. <\/p>\n\n\n\n I looked at the team\u2019s so called DoR. They had everything that is required to start\na work, primarily from a \u201cdetailed\u201d requirement perspective. What the team was missing is that they never\nlooked into their Definition of Done (DoD) to create their readiness list. <\/p>\n\n\n\n For instance, if my DoD is to get the increment for production\ndeployment, then my readiness list should have all the items that are required\nto get my feature till production, and not just a detailed requirement. This include environment availability,\nversion control, build and integration pipelines, test automations (both\nfunctional and non-functional), deployment pipelines and many more. I found that the team was just looking at the\nrequirement readiness, especially from an understanding perspective, to start\nthe work and not the whole DoD, that was causing the problem.<\/p>\n\n\n\n I took sometime explaining the team, the Sprint Planning and its\nrationale. During Sprint Planning, every\nproduct backlog item that is picked up is expanded to \u2018work items\u2019 keeping in\nview the Definition of Done. Team who\nhave production ready as their DoD, will normally end up having around 100 to\n150 work items (tasks) for every Product Backlog Item. This should be a well expanded list. For those who are familiar with production\nplanning in a discrete manufacturing, it is similar to the BoM (Bill of\nMaterials) of a finished product.\n\nWhen teams complain of impediments and\nsurprises, I always tell them to go back to their sprint backlog. Team members often have the habit of keeping\nmost of the work-items, (tasks) at the back of their mind during sprint\nplanning, tagging them as \u2018I know this\u2019, its \n\u2018simple\u2019 or \u2018insignificant\u2019 - to call out, like checking access to an\nIntegration Pipeline, where granting access may have an organizational SLA of\nfive working days, impacting their sprint goal. Hence, experiment around Sprint Planning,\nkeeping the DoD focus, to surface those - so far unseen impediments. This\npractice took some time for my team to adopt. \nThey failed again few times, since it was not as easy as it appears to\nbe. After supporting them continuously\nfor few months, I was observing their sprint planning one day. I could clearly see a deeper understanding\nthat has emerged from their practice.\n\n\n\n<\/p>\n","post_title":"CHOW #203 - Scrum Team Struggle to get their Increment Done","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-203-scrum-team-struggle-to-get-their-increment-done","to_ping":"","pinged":"","post_modified":"2024-01-25 13:55:54","post_modified_gmt":"2024-01-25 13:55:54","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15501","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15062,"post_author":"27","post_date":"2020-06-17 12:10:12","post_date_gmt":"2020-06-17 06:40:12","post_content":"\n The Scrum Team that I was coaching, was one time struggling to finish the items that they have taken up for a sprint. They could not meet the sprint goal. This was discussed in the retrospective, and team brought up dependencies on another Scrum Team which is causing uncertainty and delay. The two Scrum Teams involved then decided to have, Scrum of Scrum, where the Scrum Masters would meet and oversee the progress of the work items that are dependent. This way they believed that undue waiting without having any progress visibility can be addressed. The Scrum of Scrum was followed, the progress reviewed, and my Scrum Team got the work complete by the other as agreed. Everything seem to be working fine. This time again I found my Scrum Team failed to meet the sprint goal. This time the retrospective found a mismatch in the interface designs developed by the first team causing a problem.<\/p>\n\n\n\n What do you think the Scrum Teams should now try or experiment to resolve the\u00a0dependencies between them?<\/em><\/p>\n\n\n\n Suggested Solution:<\/strong><\/p>\n\n\n\n Scrum of Scrums rarely supports collaboration. In most cases Scrum of Scrums work as \u201cby\ndate\u201d \u2013 project management reviews.<\/p>\n\n\n\n Encourage the cross-functional team members from both the teams, for\ninstance those who have their primary skill in interface design, in this case,\nto collaborate with each other on the work item that is common between them. I encouraged the team member having design as\nhis primary skill to participate in the other team\u2019s sprint planning, design\nworkshop, daily scrum etc., to understand their ways of design, contribute,\nshare how our team expect their components to work in a specific way, and why. Even sharing \u2018tests\u2019 for the interfaces to\npass. Follow the \u201cGo See\u201d principle of\nLean.\n\nDependencies can never be resolved by agreeing\nand meeting a delivery date, but creating an environment to collaborate for a\nshared understanding, and importantly the \u201cwhy\u201d. Hence collaboration between two Scrum Teams\nmeans \u2013 collaborate in planning, collaborate in design, collaborate in code,\nand collaborate in test.\n\n\n\n<\/p>\n","post_title":"CHOW # 195 \u2013 Dependencies causing delay","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"chow-195-dependencies-causing-delay","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:17","post_modified_gmt":"2024-01-25 13:56:17","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15062","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"1","filter":"raw"},{"ID":15056,"post_author":"27","post_date":"2020-06-17 12:04:47","post_date_gmt":"2020-06-17 06:34:47","post_content":"\n Systems Thinking\nis not a new term in the industry today, especially with those engaged in Agile\nTransformations. All of us would have\nseen this term referred in every possible Theme, Objective, Value Statements so\non and so forth of an organization embarked on an Agile Transformation. However, understanding and explaining Systems\nThinking requires a great context.<\/p>\n\n\n\n I grew up in a highly remote, hill stations along the Western Ghats, where Hydel Power Projects were built. Needless to say, most of the children at my age then, in high school level, live and breathe the project surrounding us, and were familiar and commonly use or refer those Hydel Power Project terminologies in our conversations, such as Grid, Turbine, Shaft, Transformers, Relay, Reservoir, Winch, Forebay dams, Catchment areas etc., It was a very small community living in the campus and my father and his friends used to meet frequently and most of the time their discussion topic will be around the project. One day, they were discussing about another similar Hydel Power Project that is being built elsewhere in the state, and the unique design of the project. I overheard this topic and was curious. Sitting alongside, I was listening to them. In any typical Hydel Project, water stored in a reservoir on top of a hill, is released though penstock pipes (See the picture), and flows to the bottom of the hill and hits the hydro turbine installed in a powerhouse. The reservoir is normally filled by collecting water from the nearby catchment areas. In the new project, which my father and his friends were discussing, the interesting design was, the water discharged after hitting the turbine in the powerhouse is collected in a Forebay dam, and a pumping station is built to pump the water up back to the reservoir at the top of the hill. It is designed in such a way to reuse water for generating electricity from the same power station.<\/p>\n\n\n\n The key point of\ntheir discussion then was the power required to pump the water back to the\nreservoir was more than the power that is being generated by the turbine. To make it simple for understanding \u2013 an\nexample, to generate 10 MW of power the project uses 15 MW of power. This is the reason why people saw this as a\nnon-viable project and condemned the engineers for poor design and lack of\nvision. I never doubted their point of\nview, not just because he is my father, but they are from accounts and auditing\ngroup of the project, whom I believe to be good at numbers by virtue of their\nprofession, and they must be correct.<\/p>\n\n\n\n Somehow this\nconversation and the project was deeply rooted in my mind, right from my high\nschool days. Even after several years, I\nused to bring up this as a topic of discussion whenever I meet with someone\nfrom the department, and all of them reconfirmed my understanding, time and\nagain.<\/p>\n\n\n\n I used to\nwonder, and for me it is unbelievable to even imagine engineers designing such\nan important infrastructure project, without a basic feasibility study. This\nproject took a prominent place and was a natural example that I quote whenever\nI happen to teach feasibility study in Systems Analysis and Design as part of\nSoftware Engineering.<\/p>\n\n\n\n Almost twenty\nyears later I was introduced to Systems Thinking, somewhere mid of 1990s, when\nI spent time to understand, apply Systems Thinking. This is the time I created a course and taught\nthis in a management school. Even at that point, this disturbing hydel project\nand concepts of System Thinking did not touch each other in my mind, until the\ntime I met with the then head of the Power Generation and Transmission Company\nof the State. We became good friends,\nand most of the time our topic would revolve around various aspects of power\ngeneration, transmission, distribution, demand, power purchase agreements and\nmany more. <\/p>\n\n\n\n In one such\nmeeting, I brought up this topic, that was so close to me for more than\nthirty-five years then, to him. I\nnarrated what I heard when I was in high school and my further discussions with\nvarious people from time to time.<\/p>\n\n\n\n He gave a long\npause and said \u201cWhat you heard from your father was absolutely right. This is one way of looking at the\nProject!! Let us get into fundamentals\u2026\u201d<\/p>\n\n\n\n Something was\ntelling me from inside, that all those I believed and heard for years until now\nis going to get a new perspective. I sat\ncomfortably. I was keen and prepared\nmyself to listen to him. <\/p>\n\n\n\n He continued,\n\u201cThe challenge in electricity, as we know, is that it cannot be massively\nstored and distributed, like any other products. Hence, the generation or production should be\nas close as possible to the demand. A\nclassic just in time. There are a number\nof ways in which electricity is generated, Hydel, Thermal, Nuclear, Wind, Solar\netc. There are few generation models\nthat can be run on demand, and few others are not. Example \u2013 we can run Hydel on demand, but not\na Windmill. A Windmill will produce when\nthere is windfall. When excess power is\nproduced by these sources, while there is a less demand it would go wate. These types of Hydel projects are designed to\nuse those excess power generated to pump the water up to the reservoir and use\nit when there is a demand. Yes, the\npower required to pump the water back to the reservoir is more than what the\nturbine generates. We shouldn\u2019t see the\nviability of a project in isolation, but look at it as a System.\u201d<\/p>\n\n\n\n At that moment,\nI saw an understanding emerging within myself, connecting this project that was\nso close to my heart for years, and Systems Thinking \u2013 Local Optimization vs\nSystems Optimization. \n\nI feel that Leaders of Organizations, have to\nclearly abstract the big picture and keep communicating it as often as\npossible, for the rest of the organization to naturally align their part of\nwork to the big picture.\n\n\n\n<\/p>\n","post_title":"How I finally learnt Systems Thinking?","post_excerpt":"","post_status":"publish","comment_status":"open","ping_status":"open","post_password":"","post_name":"how-i-finally-learnt-systems-thinking","to_ping":"","pinged":"","post_modified":"2024-01-25 13:56:44","post_modified_gmt":"2024-01-25 13:56:44","post_content_filtered":"","post_parent":0,"guid":"https:\/\/pm-powerconsulting.com\/?p=15056","menu_order":0,"post_type":"post","post_mime_type":"","comment_count":"10","filter":"raw"}],"next":false,"prev":false,"total_page":1},"paged":1,"column_class":"jeg_col_3o3","class":"epic_block_11"};
Royce himself, in this same paper\nrealizes and says that the unidirectional implementation is risky and invites\nfailure. Hence in order to mitigate this\nrisk, he introduces a five-step approach. \nIn this, the first step is, iterative interaction between various\nsequential consecutive phases. (Figure-3 \u2013 as in the paper<\/em>). While realizing that the feedbacks from some\nof the phases are never confined to the successive steps, as recommended in\nFigure-4 (as in the paper<\/em>), with \u201cProgram Design\u201d phase, <\/p>\n\n\n\n Royce goes on to recommend, \u201cDo it Twice\u201d. To Quote:<\/p>\n\n\n\n If the computer program in\nquestion is being developed for the first time, arrange matters so that the\nversion finally delivered to the customer for operational deployment is\nactually the second version insofar as critical design\/operations areas are\nconcerned.<\/em><\/p>\n\n\n\n He goes\non to say that, \u201cIt is simply the entire process done in miniature, to a time\nscale that is relatively small, with respect to the overall effort\u201d. This justifies its necessity when there are\nnew elements and unknown factors (similar to what in Agile many today call as\n\u201cSpike\u201d).<\/p>\n\n\n\n To\nsummarize, Royce, clearly identifies the risk in sequential flow of work (what\nis now popularly referred to as \u201cWaterfall\u201d), introduces iteration with\nfeedback and further goes on to recommend operational deployment of the second\nversion.<\/p>\n\n\n\n The anti-patterns are not proprietary to Agile; in my view, we can see anti-patterns of \"Waterfall\" even today.\u00a0 <\/p>\n\n\n\n Unfortunately this incorrect understanding resulted in ill-treating \u201cWaterfall\u201d in the name of well-treating \u201cAgile\u201d.<\/p>\n\n\n\n After few years, I brought this topic, in one of my personal conversations with Craig Larman. I asked, \u201cWhen many claims to be following Waterfall for years, why they have not clearly understood what Royce meant?\u201d.<\/p>\n\n\n\n \u201c\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u2026\u201d He gave a long pause.<\/p>\n\n\n\n \u201cKnowing\nthe name of something and knowing something are two different things!!\u201d.<\/p>\n\n\n\n It took sufficiently\nlong time for me to absorb and digest this statement. <\/p>\n\n\n\n The Next morning!! <\/p>\n\n\n\n As usual I went early to set up my presentation, check the office supplies and arrangements in the Training Room. <\/p>\n\n\n\n Participants started arriving. <\/p>\n\n\n\n After the initial introduction, as usual, I began my session with the question -<\/p>\n\n\n\n \u201cWhy\nOrganizations would like to adopt Agile?\u201d.<\/p>\n\n\n\n Before I start walking towards the Flipchart to write down the responses, the answer came like a flash.<\/p>\n\n\n\n<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
<\/figure><\/div>\n\n\n\n
\n
Chow
July 4, 2021
1 Comment
Chow
November 1, 2020
No Comments
Agile
August 10, 2020
1 Comment
![\"\"](\"https:\/\/pm-powerconsulting.com\/wp-content\/uploads\/2020\/11\/Figure-4-Royce.png\")
<\/figure>\n\n\n\n